Message handling

ABSTRACT

The invention relates to handling a message addressed to a client terminal, which client terminal includes a messaging client for handling said messages. The method includes the steps of receiving a message addressed to the client terminal, said message including content destined to an “upper level” application, the “upper level” application being an application, which is separate from the messaging client, obtaining capability information relating to said client terminal, checking whether said capability information includes information about “upper level” applications the client terminal supports, and conducting an action responsive to said checking phase.

CROSS REFERENCE TO RELATED APPLICATION

This is a continuation patent application of U.S. patent applicationSer. No. 13/311,075 filed on Dec. 05, 2011, U.S. patent application Ser.No. 10/558,659 filed on 11/28/2005, now U.S. Pat. No. 8,073,114, whichis a national stage application of PCT Application No. PCT/FI2005/050106filed Mar. 23, 2005.

FIELD OF THE INVENTION

The invention relates to messaging in telecommunication systems, andmore particularly to handling a message, such as an MMS (MultimediaMessaging Service) message, addressed to a client terminal.

BACKGROUND OF THE INVENTION

MMS (Multimedia Messaging Service) provides a mechanism to send forexample drawings, photographs, music or voice clips and even short videoto and from client terminals connected to telecommunication systems. Thesystem is similar to SMS (Short Message Service), which providespossibility to exchange text messages, but MMS can be applied also toother types of content. MMS system operates on the “store and forward”principle with messages being stored and possibly formatted at an MMSC(Multimedia Messaging Service Centre) when sent between users.

An MMS Relay/Server (or MMSC) is a network element or application, whichis controlled by the MMS (Multimedia Messaging Service) provider. Thiselement transfers messages, provides specific operations to the mobileenvironment and provides storage services. In a client terminal, such asmobile phone, MMS messages are handled by an MMS Client module. The MMSClient provides the content of the MMS messages to the presentationlayer so that the user can view the content.

The use of MMS for transporting data to/from applications running on topof the MMS Client is under discussion in 3GPP (Third GenerationPartnership Project) and Java Community (JSR 205 ExpertGroup) at thetime of writing this specification. The proposed system is defined in“Wireless Messaging API (WMA) for Java™ 2 Micro Edition”, Version 2.0,Proposed Final Draft, Draft 0.10a, Sep. 23, 2003, JSR 205 Expert Group.

In the proposed system, MMS messages are used as carriers forapplication data, and the MMS Client is controlled to pass messagecontents comprising application data to the respective applicationwithout processing the content itself and vice versa. Below, the term“upper level” application is used for referring to such application,which runs on top of an operating system, as a separate application fromthe MMS Client but which uses MMS messages as a carrier forcommunicating application data. Additional header fields, such as anapplication ID header field, in MMS message PDU (Protocol Data Unit) areused for identifying the source and target application of the contentsof an MMS message. By means of these new header fields the MMS Client isable to identify message content that is destined to an “upper level”application and to forward the content to the right “upper level”application.

The proposed system is expected to be approved for the 3GPP TS 23.140standard.

SUMMARY OF THE INVENTION

Now, a problem has been identified in the solution proposed by the JavaCommunity. Namely, the solution is not backward compatible with MMSClients, which do not support the proposed new header fields and “upperlevel” applications.

As described above, according to the proposal, an MMS Client, whichreceives a message carrying an application ID header field, is notsupposed to process/present such message but to forward the content ofthe MMS message to the target “upper level” application without anymodifications. However, an MMS Client, which is not aware of the newapplication ID header field, is likely to process/present the message byitself. It is likely that this violates the expectedprocessing/presentation behaviour of the MMS Client and consequently itmay result in user irritation or even legal violation for example inrelation to copyrighted material.

The problem is expected to be experienced widely during introduction ofthe “upper level” application support, when most of the MMS Clients thatare in use do not support this new feature and thus are not able tocorrectly handle MMS message content that is destined to an “upperlevel” application. Especially in person-to-person communications (forexample different games) it is likely that the sender does not or is notable to check if the recipient supports “upper level” applications ornot.

Additionally, the problem now identified in MMS Client compatibility islikely to exist also in the long run, as it is expected that newapplications using MMS as a carrier for communicating application datawill be developed continuously. Thus, a situation, in which an MMSClient receives an MMS message comprising a header field with anapplication ID that it does not recognize (that is, the MMS Clientreceives content destined to an “upper level” application it does notsupport), is likely to occur in the future. In that case the MMS Clientis unable to forward the content to the right “upper level” applicationand therefore it is uncertain how the MMS Client behaves in such asituation. So, the solution proposed by the Java Community has problemsalso in terms of forward compatibility.

This problem is now solved by providing to a network elementparticipating in message delivery, such as MMS Relay/Server, informationabout, which “upper level” applications the destination user terminalsupports, if any, the network element then modifying the message to suitthe capabilities of the user terminal, if possible.

Thus, according to a first aspect of the invention, there is provided amethod for handling a message addressed to a client terminal, whichclient terminal comprises a messaging client for handling said messages,wherein the method comprises: receiving a message addressed to theclient terminal, said message comprising content destined to an “upperlevel” application, the “upper level” application being an application,which is separate from the messaging client, obtaining capabilityinformation relating to said client terminal, checking whether saidcapability information comprises information about “upper level”applications the client terminal supports, and conducting one or moreactions responsive to said checking phase.

According to a second aspect of the invention, there is provided anetwork element for handling a message addressed to a client terminal,which client terminal comprises a messaging client for handling saidmessages, wherein the network element comprises:

means for receiving a message addressed to the client terminal, saidmessage comprising content destined to an “upper level” application, the“upper level” application being an application, which is separate fromthe messaging client, means for obtaining capability informationrelating to said client terminal, means for checking whether saidcapability information comprises information about “upper level”applications the client terminal supports, and means for conducting oneor more actions responsive to said checking phase.

The network element according to the invention may be for example an MMS(Multimedia Messaging Service) Relay/Server or an MMSC (MultimediaMessaging Service Centre).

According to a third aspect of the invention, there is provided a signalcarrying capability information relating to a client terminal, whichcomprises a messaging client for handling messages, said capabilityinformation comprising information about “upper level” applications theclient terminal supports, said “upper level” application being anapplication, which is separate from the messaging client but which usesmessages of the messaging client as a carrier for communicatingapplication data.

Such signal may be provided by a capability information storage elementsuch as a UAProf (User Agent Profile) server or by a client terminal.

According to a fourth aspect of the invention, there is provided aclient terminal, which comprises a messaging client for handlingmessages, wherein the client terminal comprises means for providinginformation about capabilities of the messaging client, the informationabout capabilities of the messaging client comprising information about“upper level” applications the client terminal supports, said “upperlevel” applications being applications, which are separate from themessaging client but which use messages of the messaging client as acarrier for communicating application data.

According to a fifth aspect of the invention, there is provided a systemcomprising a destination client terminal, which comprises a messagingclient for handling messages, and a network element for handlingmessages addressed to client terminals, said destination client terminaland network element being adapted to communicate with each other througha communication link, wherein the network element comprises:

means for receiving a message addressed to the destination clientterminal, said message comprising content destined to an “upper level”application, the “upper level” application being an application, whichis separate from the messaging client of the destination clientterminal, means for obtaining capability information relating to saiddestination client terminal,

means for checking whether said capability information comprisesinformation about “upper level” applications the destination clientterminal supports, and means for conducting one or more actionsresponsive to said checking means.

According to a sixth aspect of the invention, there is provided acomputer program executable in a network element according to claim 28.

According to a seventh aspect of the invention, there is provided acomputer program executable in a client terminal element according toclaim 30.

Dependent claims relate to certain embodiments of the invention. Thesubject matter contained in dependent claims relating to a particularaspect of the invention is also applicable to other aspects of theinvention.

The present invention provides a messaging system specific (for exampleMMS specific) solution for backward and forward compatibility issuesrelating to applications that use MMS (or some other message) as acarrier for communicating application data. Therefore the solution thatis presented does not depend on the specific applications. The solutionsaccording to embodiments the invention contribute to improving userexperience, as processing/presentation of such content of an MMS message(or some other message), which is not intended to be processed/presentedby the MMS Client, is reduced or avoided.

In some embodiments of the invention it is verified that the destinationclient terminal supports the exact “upper level” application to whichmessage content is destined. Thus, these embodiments are future-proofconsidering new applications that are developed in the future.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described by way of examplewith reference to the accompanying drawings in which:

FIG. 1 shows a simplified block diagram of an MMS messaging system;

FIG. 2 is a signalling diagram illustrating an embodiment of theinvention;

FIG. 3 is a flow diagram illustrating operation of a network elementaccording to an embodiment of the invention;

FIG. 4 illustrates a network element according to an embodiment of theinvention;

FIG. 5 illustrates a profile information storage element according to anembodiment of the invention; and

FIG. 6 illustrates a client terminal according to an embodiment of theinvention.

DETAILED DESCRIPTION

The invention is described below in connection with MMS messages and“upper level” applications that use or are capable of using MMS as acarrier for communicating application data. However, the invention isnot limited only to MMS systems, but it can be used in any othersuitable messaging system that employs equivalent “upper level”applications.

One example of the proposed “upper level” applications are Javaapplications, but the invention can be applied also in relation to anyother suitable “upper level” application. Suitable application typesinclude for example native Symbian OS (Operating System) applications,native Microsoft Smartphone applications and applications on a smartcard, such as USAT applications (UMTS SIM Application Toolkit).

According to an embodiment of the invention MMS characteristicscomponent of UAProf (User Agent Profile) information is used forindicating, which “upper level” applications a particular MMS Client orclient terminal comprising a MMS Client supports and/or whether such“upper level” applications are supported at all. The UAProfspecification includes a schema containing attributes that describe forexample the client hardware, the browser user agent and networkcharacteristics. Some of the attributes apply to MMS Clientcharacteristics and include attributes like maximum supported size,maximum image resolution, supported content types, supported charactersets, supported languages and supported transfer encoding. The use ofMMS Characteristics component of the UAProf information is defined forexample in “Multimedia Messaging Service Client Transactions”, Version1.2, Candidate Version 16-Sept-2003, Open Mobile Alliance,OMA-MMS-CTR-v1_2-20030916-C.

According to this embodiment a new attribute (or new attributes) isintroduced in the MMS Characteristics component of the UAProfinformation. The new attributes indicate whether “upper level”applications are supported at all and/or which “upper level”applications are supported. This provides to the network (for exampleMMS Relay/Server or MMSC) means for knowing if the recipient MMS Clientsupports the “upper level” application feature (or some application inparticular), and thus, the network is able to for example modify,redirect or discard the message or send an error report to the recipientand/or to the sender of the MMS message (depending on the defaultbehaviour of the service provider or user settings in the user profile),if it finds out that the recipient MMS Client does not support the“upper level” application feature or the specific target application.

At least three following alternatives for the new MMS Characteristicscomponent attributes can be identified:

1) One new attribute. The attribute indicates whether the MMS Clientsupports the feature or not. The type of the attribute is expected to be“Boolean”, the possible values for the “Boolean” attribute beingtrue/false or 0/1.

2) One new attribute. Possible values of the attribute are theapplication IDs corresponding to the “upper level” applications that anMMS Client supports. Existence of any value of application ID means thatthe MMS Client supports the feature. The attribute is expected to be of“Literal bag” type comprising a list of character strings identifyingdifferent applications the user terminal supports.

3) Two new attributes. The first one indicates, whether the MMS Clientsupports the feature, and the second one lists the values of applicationIDs corresponding to the applications the user terminal supports. Thetypes of the attributes are respectively “Boolean” and “Literal bag”,the possible values for the “Boolean” attribute being true/false or 0/1.

It must be noted that also other attributes, attribute types and/orattribute combinations may be used according to the invention.

FIG. 1 shows a simplified block diagram of an MMS messaging system. Thesystem comprises an MMS Relay/Server, which acts as an intermediate inthe transmission of MMS messages between content/service provider 102,client terminal 101 and client terminal 100. The MMS Relay/Server isalso coupled to a UAProf Server. It must be noted that the system shownin FIG. 1 is simplified and that practical system comprises variety ofother elements. For example the path between the MMS Relay/Server andclient terminal comprises typically both fixed line and wireless partand may be implemented by means of variety of different elements. Alsoother connections shown in FIG. 1 may be routed through differentelements in practical systems. The operation of the system in FIG. 1 isfurther discussed below in connection with FIG. 2.

FIG. 2 is a signalling diagram illustrating an embodiment of theinvention. An MMS message 200 to be delivered to a Destination is sentfrom a Source. The Destination may be for example the client terminal100 of FIG. 1 and the Source may be the client terminal 101 or thecontent/service provider 103 of FIG. 1. The MMS message 200 containscontent that is destined to an “upper level” application in theDestination. This content may originate from equivalent “upper level”application in the client terminal 101 (MMS Client of the clientterminal 101 sends the MMS message) or from the content/service providersystem 103.

The MMS message 200 is received at an MMS Relay/Server. After receivingthe MMS message, the MMS Relay/Server sends a notification 201 ofreceived MMS message to the Destination. The notification carriesinformation about the received message such as source, subject, class,size, priority and expiry of the message. After receiving thenotification 201, the Destination sends (right away or later) a requestfor retrieval of the MMS message 202 to the MMS Relay/Server. (The useof the notification and request for retrieval messages is basically inaccordance with MM1_notification.REQ and MM1_retrieve.REQ messages of astandard MMS implementation.) The request of retrieval contains alsocapability information identifying capabilities of the Destinationdevices MMS Client so that the MMS Relay/Server may modify the MMSmessage to suit the capabilities of the Destination device. Thecapability information may be for example a pointer to a profileinformation source element, which is in this case a UAProf Server. Thepointer may be for example an URL (Uniform Resource Locator). It is alsopossible that the MMS Relay/Server already knows the source for thecapability information, or that the MMS Relay/Server obtains thecapability information from some other means than a specific profileinformation source element. The capability information may be obtainedfor example from a static table or derived on the basis of theDestination devices type or model.

The maintenance and updating of the capability information in the UAProfServer is conducted in accordance with prior art methods and thus it isnot discussed any further herein.

Once the MMS Relay/Server knows the source for the capabilityinformation it sends a request for capability information associatedwith the Destination 203 to the UAProf Server and the UAProf Serveranswers with capability information 204. MMS Relay/Server processes thecapability information in phase 205. The MMS Relay/Server may haveidentified that the MMS message or part of its content is destined to an“upper level” application when it first received the MMS message or whenit received the request for retrieval message 202 from the Destinationor this may happen now in phase 205. On the basis of the capabilityinformation and characteristics of the MMS message the MMS Relay/Serverthen conditionally forwards the MMS message 206 to the Destinationeither with or without modifications. (However, it is possible that theMMS message is not sent to the Destination at all, if the Destination isnot compatible with the content of the MMS message.) Differentalternatives for handling messages containing “upper level” applicationdata are further discussed in connection with FIG. 3 below. FIG. 3 is aflow diagram illustrating operation of a network element according to anembodiment of the invention, the network element being a networkelement, which acts as an intermediate in message transmission, such asan MMS Relay/Server of FIGS. 1 and 2.

First the network element receives a message containing content that isdestined to an “upper level” application in a destination device inphase 300. A message is identified to contain such content for exampleby means of the new header fields introduced in the Java Communityproposal discussed above: “Wireless Messaging API (WMA) for Java™ 2Micro Edition”, Version 2.0, Proposed Final Draft, Draft 0.10a, Sep. 23,2003, JSR 205 Expert Group.

Then, in phase 301, the network element obtains capability informationrelating to the destination device to which the message in question isdestined. As described above in connection with FIG. 2, the networkelement may ask for the capability information from a suitable source.On the basis of the capability information the network element thenchecks in phase 302, whether the destination device supports “upperlevel” applications.

If the destination device does support “upper level” applications, theprocedure proceeds to phase 303, in which it is checked, whether thedestination device supports the exact application to which the contentin the message is destined.

If the destination device does support the right “upper level”application, the message is forwarded to the destination device withoutany modifications in phase 304. However, when needed, the networkelement may format the message in a suitable manner, but such formattingis not required because of the “upper level” application content in themessage.

If it is concluded in phases 302 or 303 that the destination device doesnot support “upper level” applications at all or that the destinationdevice does not support the right “upper level” application,respectively, the process proceeds to phase 305. Therein, the messagecan be either discarded as unsuitable for the destination device or itmay be modified so that it suits the destination device and be thenforwarded to the destination device. Alternatively, the message may beredirected to some other destination or the network element may simplystop the process of handling the message. The network element may alsosend an error report to the destination device thus informing the usersthat somebody is trying to send them content, which is not compliantwith the devices they are using. In addition to the destination, orinstead of the destination, an error report may be sent also to thesource of the message, the source being for example another clientterminal or a content provider. (The actual message may be for examplediscarded in connection with sending an error report.) In addition, theservice provider providing MMS messaging services may decide to handlethe situation, in which the destination device does not support thedestination application, in some other way. Also destination user's (orsender's) user profile or preference/settings in the network or contentprovider's settings may have an impact on how the messages are handled.

One way of modifying the message in the case that the destination devicedoes not support the right target application is now presented as anexample. Even if the client doesn't have the right “upper level”application, there might be some other “upper level” application(s) thatmight be able to do something with the data contained in the message.For example, if the data contained in the message is XML (eXtendedMarkup Language) formatted textual data, there is possibility to show itin a normal text editor. Thus the network element may modify the messagein phase 305 for example so that it will be delivered to some other“upper level” application that to the one to which it was originallydestined.

It must be noted that the flow diagram of FIG. 3 may be altered in anysuitable manner For example phases 302 and 303 may be easily combinedinto one checking phase depending on the implementation of thecapability information. It is also possible that the phase 303 or 302 iscompletely excluded from the process. Similarly, the behaviour of theMMS Relay/Server, MMSC or other network element in response to thecapability information can be kept implementation/service providerspecific. Users may be given a possibility to set a preference forhandling incompatible message content in their user profile. Possiblevalues for the preference could be for example delete, re-direct ormodify the message. Nevertheless, a service provider may want to definewhat kind of applications it wants to support (person-to-person and/orcontent provider-to-person). To this end, the service provider may setsome default values/options in the user profiles.

FIG. 4 illustrates a network element 400 according to an embodiment ofthe invention. Such network element may be for example a MMSRelay/Server or a MMSC or some other network element that stores andforwards messages to client devices.

The network element 400 comprises a processing unit 401 and aninput/output module 403 coupled to the processing unit 401. Theprocessing unit 401 is coupled to a memory 402 as well. The memorycomprises computer software executable in the processing unit 401.

The processing unit controls, in accordance with the software, thenetwork element to receive a message addressed to a client terminal, themessage comprising content destined to an “upper level” application inthe client terminal. The network element is controlled to obtaincapability information relating to the client terminal, to check whetherthe capability information comprises application information about“upper level” applications the client terminal supports, and to conducta specific action responsive to the result of the checking. The specificaction that the network element takes may be for example one of thefollowing: modifying the message, discarding the message, redirectingthe message, sending an error message and forwarding the message as suchor with modifications to the client terminal.

FIG. 5 illustrates a profile information storage element 500 accordingto an embodiment of the invention. Such profile information storageelement may be for example a UAProf Server.

The profile information storage element 500 comprises a processing unit501 and an input/output module 503 coupled to the processing unit 501.The processing unit 501 is coupled to a memory 502 as well. The memorycomprises computer software executable in the processing unit 501 andUAProf information containing information about capabilities of variousclient terminals. Specifically the UAProf information in the memory 502comprises application information about “upper level” applicationsdifferent client terminals support, the “upper level” applications beingapplications that use or are capable of using messages of the messagingclients as carriers for communicating application data.

The processing unit controls, in accordance with the software, theprofile information storage element to provide capability information ofa certain client terminal upon request and specifically, the profileinformation storage element is controlled to provide, upon request, theapplication information relating to “upper level” applicationsassociated with a certain client terminal.

FIG. 6 illustrates a client terminal 600 according to an embodiment ofthe invention. The client terminal may be for example a mobile phone, apersonal information device, a laptop provided with communicationcapabilities or some other communication device.

The client terminal 600 comprises an MMS Client 601, an “upper level”application 602, which uses messages of the MMS Client as a carrier forcommunicating application data, and a radio frequency part 603. The MMSClient receives and sends data to other devices via the radio frequencypart 603 and conveys data to and from the application 602. The clientterminal comprises also memory (not shown), a processing unit (notshown), which is responsible for the computation operations executed inthe client terminal, a user interface (not shown), which typicallycomprises a display, a speaker and a keyboard with the aid of which auser can use the client terminal 600.

The memory of the client terminal comprises software executable in theclient terminal. The MMS Client of the client terminal is controlled inaccordance with the software to provide information about capabilitiesof the MMS Client, the information comprising information about “upperlevel” applications the client terminal supports. The information may begiven for example as a pointer to a profile information storage or asreadily usable capability information.

Particular implementations and embodiments of the invention have beendescribed above. It is clear to a person skilled in the art that theinvention is not restricted to details of the embodiments presentedabove, but that it can be implemented in other embodiments usingequivalent means without deviating from the characteristics of theinvention. The scope of the invention is only restricted by the attachedpatent claims.

1. (canceled)
 2. A method to be performed by a client terminal (100,600), which comprises a multimedia messaging client (601) for handlingmultimedia messages, wherein the method comprises providing, to anetwork element, information about capabilities of the multimediamessaging client, the information about capabilities of the multimediamessaging client comprising information about upper level applications(602) the multimedia messaging client of the client terminal supports,said upper level applications (602) being applications, which areseparate from the multimedia messaging client and which use multimediamessages of the multimedia messaging client (601) as a carrier forcommunicating application data.
 3. A method according to claim 2, themethod comprising giving said information about capabilities of themessaging client as a pointer to a profile information storage.
 4. Amethod according to claim 2, the method comprising giving saidinformation about capabilities of the messaging client as readily usablecapability information.
 5. A client terminal (100, 600), which comprisesa multimedia messaging client (601) for handling multimedia messages,wherein the client terminal comprises means for providing, to a networkelement, information about capabilities of the multimedia messagingclient, the information about capabilities of the multimedia messagingclient comprising information about upper level applications (602) themultimedia messaging client of the client terminal supports, said upperlevel applications (602) being applications, which are separate from themultimedia messaging client and which use multimedia messages of themultimedia messaging client (601) as a carrier for communicatingapplication data.
 6. A client terminal according to claim 5, whereinsaid information about capabilities of the messaging client is given asa pointer to a profile information storage.
 7. A client terminalaccording to claim 5, wherein said information about capabilities of themessaging client is given as readily usable capability information.